Reorganizing logical memory space is deliberately performed for a variety of reasons, including security and wear leveling. For example, occasionally changing a physical location where data is stored can make it harder for an attacker to either misappropriate the data or trigger targeted location wear. Wear leveling is used for memory devices with endurance issues to more evenly distribute use-based wear by periodically relocating frequently accessed data to other physical locations within memory; while wear leveling is most commonly associated with flash memory, most memory forms including dynamic random access memory (DRAM) can ultimately suffer use-based wear, and thus can also benefit from wear leveling.
A CPU or other “master” in these circumstances still needs to read, write and otherwise manage the data that has been shuffled or reorganized; an address translation mechanism is used to make that happen. Usually, a look-up table stored in processor cache or local memory is retrieved and used to determine a logical-to-physical mapping corresponding to a desired logical address. For example, in connection with a read or write command, the master (e.g., a memory controller) first retrieves this table and uses it to perform address translation to retrieve a true “physical” address from the look-up table. Once the memory controller has “translated” the logical address to a physical address, it then issues a read, write, refresh or other command to the memory device, corrected to the true memory location.
Unfortunately, as memory becomes increasingly dense, the translation overhead begins to impose too great of a penalty. For example, for an 8 gigabyte flash memory space, an address translation table on the order of 27 megabytes is typically needed and, for a 16 gigabyte flash memory space, a 54 megabyte translation table is typically needed. Not only does the relatively large table size add unacceptable storage overhead, inhibiting local storage of the table, but the large size also requires per-transaction data clock cycle overhead. For example, some designs may require a look-up table that is too large for cache; a memory controller must therefore await return of this data before it can look-up the true address, and only then can the controller issue a corrected memory access command. This latency interferes with the ability to pipeline memory commands and can be unacceptable for many applications.